Working with OLE 1 Clients
This section
describes some of the idiosyncrasies of working with OLE 1 clients.
A successful
call to the IOleClientSite::GetContainer
The IOleClientSite::ShowObject
When an OLE 1
client contains an OLE 2 object and the object is activated or the OleUpdate
function is called, the aspect of the data returned will always be
DVASPECT_CONTENT. This is because OLE 1 clients have no concept of a FORMATETC
OLE 1 clients
can link to OLE 2 objects only if the link source:
is represented by a file
moniker or a generic composite moniker consisting of a file moniker and one
item moniker.
is not an embedded OLE 2
object.
An OLE 1
client can contain an incompatible link when a linked object is pasted from an
OLE 2 container into the OLE 1 client or when an OLE 2 container saves the data
to an OLE 1 file, to allow the OLE 1 version of the application access to its
data. When the OLE 1 client loads the incompatible link, the link is converted
to an embedded object and assigned the class name Ole2Link. The OLE 1 client
cannot connect to the link source. However, if the newly embedded object is
then pasted into an OLE 2 container using the Clipboard, or converted to an OLE
2 object using the OleConvertOLESTREAMToIStorage
When the link
source for an OLE 1 linked object changes its name, the link can remain intact
only if the file moniker for the link source has changed. That is, if the link
source is a range of cells within an OLE 2 spreadsheet application and the name
of the file that contains the cell range changes, OLE will track the link.
However, if the name of the cell range changes, the link will break.
Pasting an
OLE 2 linked object into an OLE 1 client document and then calling the OleCopyFromLink
function to convert it to an embedded object will fail if the data transfer
object provided by the link source does not support the IPersistStorage